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(57) Abstract 

A teleconununicatiOTs rewanl method provides tclecOTimunlcations services rewanls for purchases made by members. The 
reward m«ahod ftequenUy updates the member's reward profiles so tfiat rewanls arc virtually instantaneous. TTic rewards consist of 
telecommumcations services, for example long-distance call minutes or cellular telqAone air time, and are easUy redeemed. Apparatus for 
implementing the method includes a high-level control centre and a database managemeot system. 
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TELECOMMUNICATIONS REWARD METHOD 

Field Of The Invention 

The present invention relates to telecommunications reward 
methods and is particularly concerned with the rewards based on 
consumer purchases. 

Background Of The Invention 

The use of loyalty rewards programs to retain existing customers 
and to entice new ones to purchase or use a particular product has 
become persuasive amongst retailers from grocery chains to petroleum 
companies and also amongst credit card companies who provide a 
reward of some sort or another for using their card rather than a 
different credit card. One of the problems with these reward programs 
whether it is air miles for gasoline purchases or credits toward an 
automobile purchase for using a particular credit card, is that they do 
not provide something which has immediate value to the participant in 
the rewards program. 

Summarv Of The Invention 

An object of the present invention is to provide an improved 
telecommunications reward method. 

In accordance with an aspect of the present invention there is 
provided a method of providing telecommunications rewards to a 
member comprising the steps of generating a point-of-sale transaction, 
relating the point-of-sale transaction to a member of telecommunications 
awards, determining value of reward in dependence upon the point-of- 
sale transaction, updating a member's profile for the member by the 
value determined. 

Accordingly the method of the present invention combines known 
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technologies in such a way as to create a system whereby participants 
in a rewards program can be given telecommunications access time, e.g. 
long distance time, Internet access time or cellular telephone air time, in 
return for purchases and the reward would be credited and available for 
5 use immediately following the purchases. 

The method relates a purchase to an immediate reward for 
telecommunications access time by identifying the purchase as eligible 
for a reward through a member database for example a UPC code 
scanner database or a credit card magnetic strip database which then 
10 communicates to a telecommunications debit platform which in turn is 

interfaced with a long distance or cellular provider. 

Advantages of the present invention are as follows: 

• Providing a link to purchases with instant gratification of 
telecommunications credits, for example in telephony long 

1 5 distance or cellular minutes and in data communications 

access time to services or the Internet. 

• There is thus no need to save up or receive a statement 
prior to using the credit, a participant in the rewards 
program would be able to utilize the reward immediately 

20 following the purchase for which the reward was granted. 



Brief Description Of Drawings 

The present invention will be further understood from the 
following description with references to the drawings in which: 

Figure 1 illustrates, in a flow chart, an overview of the reward 
25 method in accordance with an embodiment of the present invention for 

a magnetic strip card user; 

Figure 2 illustrates, in a flow chart, an overview of the reward 
method, in accordance with an embodiment of the present invention an 
overview of the metfiod for a UPC code card holder: 
30 Figure 3 illustrates, in a flow chart, the reward method in 
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accordance with the embodiment of the present invention; 

Figure 4 illustrates in a block diagram apparatus used by the 
method of Figure 3; 

Figure 5 illustrates, in a flow chart, an overview processing data 
flow for the reward method of Fig. 3; 

Figure 6 illustrates. In a block diagram, input activities of the 
method of Fig. 3; 

Figure 7 illustrates, in a block diagram, reward transfers; 

Figure 8 illustrates, in a flow chart, the file processing data flow 
for the reward method of Fig. 3; 

Figure 9 illustrates, in a flow chart, member lead processing data 
flow for the reward method of Fig. 3; 

Figure 10 illustrates, in a flow chart, member enrollment 
processing data flow for the reward method of Fig. 3; 

Figure 11 Illustrates, in a flow chart, the reward transaction 
process for the reward method of Fig. 3; 

Figure 1 2 illustrates, in a flow chart, transaction processing data 
flow for the reward method of Fig. 3; 

Figure 1 3 illustrates in a block diagram outbound activities for 
apparatus used by the method of Figure 3; and 

Figure 14 illustrates, in a flow chart, statement processing data 
flow for the reward method of Fig. 3. 

Referring to Figure 1 there is illustrated in a flow chart an 
overview of the method in accordance with an embodiment of the 
present invention. 

At step 1 , as represented by a card 1 0, a point-of-sale transaction 
is initiated. 

Step 2, a member card is swiped through a magnetic strip reader, 
as represented by a block 12, as in a typical point-of-sale transaction. 
Step 3, a credit card (or debit) card database is accessed, as 
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represented by a block 14, to confirm the transaction. Thus far the 
method proceeds as is well known with point-of-sale transactions. 

Step 4, a field in the card holder record, in the database 14, 
identifies the card holder as a member of the reward plan. Responsive 
5 to the presence of this identification a datalink is established, as 

represented by block 1 6, to an appropriate debit platform, steps 5a and 
5b, as represented by blocks 18 and 20. For simplicity, only long 
distance 1 8 and cellular 20 debit platforms are illustrated. However, the 
actual debit platform used could be a telecommunications services 

1 0 platform. The telecommunications services platform could credit the 

member with long distance or cellular time or a host of other services, 
such as Internet access time, voice messaging, call waiting, and calling 
number identification. Individual member profiles could be used to 
distribute rewards between the various services or to other users. For 

1 5 example to a daughter away at University. 

The rewards method is completed by step 6, by the member using 
the telecommunications reward, as represented by block 2. 

Similarly Figure 2 illustrates an overview of the method for a 
member having a UPC type card at step 1 , as represented by a UPC card 

20 24. 

At step 2, a member's card is held to a UPC code scanner, as 
represented by block 26, as is typical in a point-of-sale UPC transaction. 

At step 3, a UPC code card database is accessed, as represented 
by a block 28 to confirm the transaction. 
25 At step 4, a field in the current holder record in the database 28 

identifies the cardholder as a member of the award plan. Responsive to 
the presence of this identification a data link is established as 
represented by block 1 6. The remaining steps in the method are the 
same as in Figure 1 . 

30 Referring to Figure 3 there is illustrated in a flow chart a reward 

method in accordance with another embodiment of the present 
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invention. 

The method begins at step 1 with a point-of-sale transaction 
being collected, as represented by block 30. Step 2, transactions are 
aggregated and sorted as represented by block 32. An associated 
transaction file, as represented by block 34 is created by the first and 
second steps. At step 3, transactions are rated to determine number of 
seconds to be rewarded, as represented by a block 36. in order to 
accomplish this rating, a rewards rating table, as represented by block 
38, is consulted. At step 4, any special treatment required for members 
is determined and rewards are calculated. Special treatment is 
determined by consulting a member profile, as represented by block 42, 
and a rewards file is created as a result of step 4, as represented by 
block 44. At step 5, the member's profile is examined and rewards are 
updated on the member file, as represented by block 46. The updated 
member profile is represented by a block 48. At step 6, a master 
update process is performed on a debit platform as represented by block 
50. A debit system member profile is updated as represented by block 
52. The method is completed at step 7, when a member phones into 
the system and consumes rewarded time as represented by a block 54. 

Referring to Fig. 4, there is illustrated a reward system 100 
comprising a high-level control centre (HCC) 102 and an information 
works (IW) 104. The IW 104 includes a transaction processor (IW/TP) 
1 06 for partner management, member management, and reward system 
calculations and an data warehouse (IW/DW) 108. The HCC 102 
includes a Customer Service Centre (CSC) system 110 and a debit 
platform with interactive voice response (IVR) 112. 
The method is a database-driven relationship marketing program, 
there are four distinct business components. 

Transaction Processing (IW/TP) Database Management System 106; 
Data Warehouse (IW/DW) Database Management System 1 08; High- 
level Control Centre for Debit Platform 102; and IVR systems (IVR) 
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112. 

Now to address the system functionality as well as describe the inter- 
relationship of the Customer Service Centre, Debit Platform and IVR 
components with InfoWorks' components: Transaction Processing 
5 and Data Warehouse Database Management Systems. 

Referring to Figure 5, there is illustrated, in a flow chart, an overview 
processing data flow for the reward method of Fig. 3. Advantages of 
the present system are: 
I. * Immediate gratification with "real-time" reward accumulation and 

1 0 reden:4)tion. 

Conceptually unique, technology-based coalition loyalty program. 

* High appeal, easily attainable reward currency. 

* Preemptive opportunity to link land-based long distance with cellular 
mobility. 

15 * Debit Platform offers enteuiced customer telecommunications services. 

* Opportunity for value-added credit card overlay with innovative functional 
enhancements. 

* Commitment to data driven Customer Value &ihancement strategies for 
partners. 

20 * Network time, I>ebit Platform, and marketing databases supported by blue 

chip providers. 

Longer term opportunity exists for Members and Partners to ride the 
information highway into diiect-to-home enteitainment/informatiGB^ ser 

* Global expansion opportunities with significant ROI. 
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Overview of Reward Process 
*Members in the program earn their points 

automatically through electronic Point of Sale (PCS) tracking when they shop 
at participating Partner. 

The IW/TP System collects and processes the Member purchase transactions 
and assigns the appropriate reward points. 

The reward redemption process includes calling the IVR system via a 1-800 
telephone number. 24 hours a day, 7 days a week: Members will call a 1-8(X) 
number, Enter their unique Member Number and password. Place a call with 
a telephone number of their choice 

The HCC/Debit Platform is tte data manager of the redemption process and is 
die vehicle that Members use to redeem their reward points. 

HCC/rVR platfoim is a voice-assisted telephony system. The IVR system is a 
vehicle for: Customer Service, Program Information, Member fcroliment. 
Customized adveitising. Branded messaging. Branded marketing surveys. 

For service, Members may access a live operator at the CSC (Customer 
Service Centre) . 

Database Managemmt Systems 

Data Warehouse and Transaction Processing Database Management Systems 
allow for an extremely flexible environment supporting several basic, but 
different business functions. Together, they support: 
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• Integration with a first class customer service system 

• High volume transaction processing 

• Detailed management reporting and EIS systems 

• Partner reporting 

5 • Basic analytics and the IW Customer Value 

Scorecard"* 



Marketing information retrieval and advanced 
analytics 



Objectives of the Database Management Systems 

10 • Design and support a system that is driven by the anticipated 

marketing information requirements, with the flexibility to adapt 
to changing market d)mamics. 

• Ensure seamless connectivity between the Database Systems, 
Customer Service Centre, Debit Hatform, IVR and external 

1 5 suppliers and vendors. 

• Ensure data integrity by developing appropriate edits, controls, 
audits and procedures. 

• Meet the growth requirements of the program in terms of 
membership, parmership, and more detailed transactional data, 

20 i.e. product categories or SKU. 

• Ensure the system architecture has the necessary through-put 
and offers flexibility, scalability and portability to manipulate 
and report information in tfie database. 

• Contimiously enrich the Member Profile information though 
25 survey data, file overlays and tracking of response data. 
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• Deliver dynamic analytic services to siqjport Customer Value 
Enhancement (CVE) maiiceting strategies. 

The development of the functional design, system specifications, 
programming, simulation, training and implementation of the 
system will take place as two deliverables. 
IW/TP System Architecture-Pipeline and parallel processing 
The architecture of the IW/TP engine will include many asynchronous 
processes to handle different stages of transaction processing. The processes 
will be similar for each transaction type; they will be kept simple; and they 
will support pqieline and parallel processing. This architecture allows many 
processes to be reused for differem transaction types. Communication 
processes can be common to many transaction types and for many parties. 
Separate processes to handle the communication links, to load transaction files 
into the database; and to process the transactions within the database will 
simplify the maintenance of the programs. Simple changes to file formats and 
support for new communication methods could be implemented without 
touching the transaction processing processes. The migration from a batch 
engine to a real-time engine could be done quickly by providing a new loader 
process on top of the existing processing processes. 

Inbound Processes 

The processes (or software modules) for an Inbound transaction will be: 

* File recq}tion (from communication line or media), 

* Basic file validation (number of trans.; transaction formats), 

* File segmentation (broken into "work" units). 

* Segment loading (in a work area), 

* Segment validation and computations (still in a work area). 

- Detect and log validation errors 

- Conq}ute any necessary quantity (Rewards, Offers) 

* Segment insertion (imo final database) 

Referring to Figure 5. there is illustrated, in a flow chan. prx)ccssing data 
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flow for the system. And in Figure 6, there is illustrated, in a block diagram, 
iiqmt activities of the system. 

Outbound processes 

The processes (or software modules) for an outbound transaction will be: 
5 * Create outbound transactions (select a set for transmission). 

* Create outbound file (for outbound transactions) 

* File transmission (to communication line or media) 

Transaction Types and Input Activities 

* Member Lead (prospect data) 

10 * Member Enrollment (basic Member data) 

* Member Profile changes (demographics) 

* Member Purchases (POS transactions sent by Partners to 
IW/TP) 

* Reward Credits (Member Base Offer and Special Offer 
15 points) 

* Reward Debits (Debit Platform redemption of points ad 
call detail data) 

* Reward transfers 

* Member IVR Message control (what messages to play) 
20 * Member IVR Response (responses to branded messages 

and surveys) 

* Customer Service Messages (problems and resolutions 
about Members) 

* Fulfillment Request message (control for Member 
25 fulfillment) 
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* Mail-Out Message Flags (Fulfillment) 

* Database Synchronization (shared table 
additions/updates) 

* Transaction Acknowledgment (processing audit 
control). 

Member Lead (ML) 

A prospect may enroll into the reward system program 
using one of the various methods that are available: 

• Customer Service Centre 

• IVR 

• Mail-in order form via Data Entiy 

• Internet * 

• Electronic Kiosk * 

• Partner "auto-enrollment" information 

• Partner "auto-prospect" infonnation 

Regardless of which enroUment method is chosen, a new Member Lead 
transaction is generated and sent to IW/TP. 

The transaction layout is die same as the Member Enrollment (ME), except 
the transaction identifier is "ML" and the Member Number must be blank. A 
unique refereiK^e number is assigned to the transactions and stored in the 
MEMBER_I£AD table. CSC is responsible for returning a clean Member 
Enrollment (ME) transaction with the assigned reference number. This 
reference niunber will be used to update the MEMBER_LEAD table as 
accepted or rejected. If the lead is rejected, a reason code will be provided by 
CSC. 
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Member Enrollmeiit (ME) 

All Member Enrollment transactions will be stored for auditing purposes. The 
CSC is responsible for validating all information on prospective Members. 
The new Member information may be generated via the IVR system, or 
5 Member Lead transactions sent from IW/TP. Once an individual's request 

for enrollment has passed validation. CSC will: 

1 . Assign a unique Member Number 

2. Activate the Monber Nimiber on the Debit Platform 

3. Send a Member Enrollment (ME) transaction to 
10 IW/TP. 

4. If the new Member Lead was provided by IW/TP, 
then the reference nimiber must also be included on 
the ME transaction. 

5. If a new Member Lead is rejected by the CSC, a 

1 5 reason code will be sent to IW/TP for updating of 

the MEMBER LEAD table. 

Monber Profile changes and updates 

Member Enrollment is divided into two categories: 



1. Basic profile which inchides name, addresses, phone 
20 numbers, etc. 

2. Demographic profile which includes answers to 
various survey questions 
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aj Base 

If any profile information changes on a given Member, all 
information (fields) will be transmitted fiom CSC to IW/TP 
using the Member &nx)llnient transaction. The following 
transaction type code will be used to control the iqxJate process. 

=» N - new Member enrolled 

-» U - update current Members profile 

a) Demographic 

For demographic profile updates, CSC will only transmit the 
information that has changed. A Member Eorolhnent type 
ME02 transaction will be used to provide this demographic 
information. 



Member Purchase (MP) 

When a Member purchases various items at a Partner's location and presents 
their reward system Membership card, the Partner is responsible for 
transmitting the {Rirchase transaction to IW/TP using one of the certified 
transmission methods. This purchase transaction is translated into reward 
points and the Member's balance is updated. Each purchase transaction will 
generate a Reward Credit transaction. Multiple Reward Credit tranMrtinn^ 
will be sorted and groupe d into blocks for transmission to HCC 

Reward Credit (RC) 

A Reward is a reward system quantity of pomts purchased by a Partner or 
FTC for a Member. This Reward Credit transaction contains a description of 
a Member's purchase, date/time. Partner, location, transaction purchase 
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amount and the Reward points. This transaction is typically sent by IW/TP to 
HCC and serves two functions: 

1. CSC will receive Reward transaction details to assist 
them with Member inquiries. 

5 2. Debit Platform is given the Reward Credits to 

increase a Member's point balance for potential 
redemption via long distance or cellular phone calls. 

All reward credit transactions should have an offer code or 
other field to identify the source. 
Reward Debit (RD) 

Each time a Member calls into the Debit Platforai and makes an outbound 
call, a Reward Debit transaction is getierated. This redemption transaction will 
record: 

• caller's stan time 

• caller's end time 

• destination number (or description, i.e. movie title) 

• total reward consumed and subtracted from the Debit 
Platform 

• redenqition currency code (i.e. cellular, long 
distance, video) 

• Call detail information 

HCC will transmit all Reward Debit transactions to IW/TP. 
IW/TP will update die Member's monthly redemption 
accumxilators, store and archive the transaction for analytical 
25 reporting and statementing. 

The Reward Debit transaction is defined so that other 



10 



15 



20 
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redemption curremies are possible. 
Reward Transfer 

Any Member can transfer rewards from themselves to anoflier Member. This 
transfer may be initiated by a Member within the IVR system. A transfer is 
simply a Reward Debit transaction for the initiating Member and a Reward 
Credit transaction for the receiving Member. Each transaction will be 
idemified with both Monber Numbers and the same reference number. If 
CSC representatives are allowed to transfer rewards on behalf of a Member, 
then security must be in place to ensure rewards are not transferred to 
common Member numbers (themselves, friends, etc.). 

Referring to Figure 7 there is illustrated, in a block diagram, reward transfers. 
Member IVR Message flags (IM) 

This transaction controls the branded message switches for the IVR system. 
These flags instruct the IVR system to play specific targeted advertisement 
messages for individual Members. This transaction can be generated by an 
analytical process according to some business rules via the IW/DW system. 
The transaction will update the Member's message profile and is passed on to 
the Debit Platform for IVR processing. 

Each message wiU have an effective date and expiry date. The IVR system is 
responsible for deactivating the message once it is played and returning an 
rVR Response transaction. 



rVR Response (IR) 

Whenever a Member calls into the IVR system and is prompted for various 
messages and/or surveys, an IVR response transaction wUl be sent to IW/TP 
for future analysis. Which message/survey generates these transaction wiU be 
the responsibUity of reward system and HCC. The data stoied would indicate 
how long they Ustened to a specific message (i.e. % completed, zero^ut. 
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hung-up), as well as the response codes from survey questions. 



CSC Message (CM) 

All calls made to the CSC by a Member will be recorded. The problems, 
complaints, messages, and resolutions are categorized then sent to IW/TP for 
5 insertion into the IW/DW database for future analysis. 



Mail-Out Message Flags (MF) 

Controls the Mail-Out messaging flags. These flags will iostnict the statement 
processing fiilfillment house which messages, flyers, advertisement should be 
included with the statement. These transactions are gei^rated by IW. reward 
1 0 system Account Managers arc part of the process of defming requirements. 

Database Synchronization (DS)Most database tables in the IW/TP system are 
updated via transactions. However, not all tables require a specific 
transaction type like Member Enrolhnent (ME) or Member Reward (MR). 
The Database Synchronization (DS) transaction is the "catch-all" transaction 
1 5 for all other database synchronization transactions. 



Transaction Processing Acknowledgments (TA) 

Processing acknowledgments transactions are generated by remote sites on 
transactions sent by IW/TP to them. This mandatory information allows 
IW/TP to track the transactions it generates. It ensures that a mnote site 
20 actually received and processed the transaction file sent by IW/TP. 

Acknowledgments will be processed by IW/TP the same way as any other 
inbound transaction. This will also gready simplify the synchronization of 
different systems. 



Control Processing 
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Referring to Figure 8 there is illustrated, in a flow diart, the file processing 
data flow for the reward method of Fig. 3. 
File Reception 

All files are transmitted via pred^nnined telecommunication interfaces. Each 
5 party will be assigned an unique USERID which will allow them to transmit 

files in to their own directory. Transmitted files are automatically located aiul 
recorded in the IN_FILE_CONTROL table with a unique file control number 
as "RECEIVED". The files header information and date/time of i«cq)tion is 
also recorded. The file will then be moved to a designated processing area for 
1 0 validation. 

High Level Validation 

The IN FILE CONTROL table will be automatically scanned at tegular 
intervals for "RECHVED" files. The file header is checked for validity: 



• Transaaion type using the system edit table 

• Loyalty Program using the system edit table 

• Partner ID using the Partner table 

• Service centre using the system edit table 

• File sequence number to ensure diis file has not 
already been transmitted using die 
IN_FILE_CONTROL table. 

• Date and time 

Each detaU record is validated to ensure all number fields are numeric and 
selected control fields are accumulated. All control fields are checked against 
die trailer record. If any errors are found an error log and t^rt will be 
generated. These errors will be communicated to the sending party according 
to a pre-defined procedure for that specific parly. A successfiil validation will 
update the file status to "VALID" 
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Disaster Recovery Copy of iiqnit files 

All files tiiat will be scheduled for processing will be copied and sent to the 
off-site backup server. The backup server will hold a copy of all Hies 
received and transmitted to connectipg parties. These files will be used for 
5 recovery purposes in case of disaster or system failures. The backup server 

must have die capability to istore a minimum of all files received and 
transmitted since the last Ml off-site system backup. Upon successful 
transmission, the IN_FILE_CX)NTROL disaster recovery field is updated to 
"SENT". 

File Segmentation 

File segmentation is the processing of breaking up files to be processed into 
smaller work units. These work units can be processed using parallel 
processing. This means multiple units of woric can be process simultaneously. 
The IN FILE CONTROL table is scanned for files with a status of 
"VALID". The selected file is then segmented into smaller wo± files. The 
size of a segment will depend on the transaction type and is controlled using 
the system EDIT_TABLE. Each segment is assigned a number and each 
transaction will be assigned a unique tracking ID. Once a segmem is 
completed, the segment name, transaction type, and size is added to the 
SEGMENT_CONTROL table with the status "LOADED". 

Segment Validation and Preprocess 

This process will scan the SEGMENT_CONTROL table for "LOADED" 
segments. Each time a loaded segment is encountered the stams is changed to 
"PREPROCESS". The prq>rocessing of each transaction will consist of 
25 validating member codes, location codes, message codes, etc. All 

preprocessing functions that require table lookups, calculating of rewards are 
performed and the results stored with the transactions. All transactions that 
have error conditions or marked for suspend are marked with an i^)propriate 
error message code and stored in the ERROR CONTROL table. 



10 



15 



20 
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When processing segment has been completed the segment status is chained to 
"PROCESSED". 

Audit and Control 

Up to this point the only production database tables being updated are the 
5 IN_FILE_CONTROL and SEGMENT CONTROL tables. AU other tables are 

woric areas. If a system failure occurs any time after file reception, no 
production data recovery is required. As part of the system startup 
procedures: 



• All work areas will be deleted 

10 • All SEGMENT_CONTROL entries wai be deleted 

that have not been "COMMITTED". 

Segment Process and CommitEach segment marked "PROCESSED" is 
located and any additional processing (if required) is completed. Additional 
processing will be required only if the result of tfie processing is dependent on 

15 the current status of a Member. An example would be if a Member's status 

level changes based on the accumulated rewards for a given Partner. The 
result changes the calculation of the reward on the next transaction for the 
same Member. AU transactions are inserted into Ae production database and 
all updates are jqiplied to the production databases. At the end of a segment 

20 all updates are committed to the database and the SEGMENT_CONTROL 

entry is changed to "COMMITTED". Once all the segments for a given irput 
file have been committed tten the IN_FILE_CONTROL entry is changed to 
"COMMITTED" along with the date and time, total number of transactions 
processed, and die total number of errors. 

25 Audit and Controls 

All segments that require the updating of the same database tables will be 
updated asynchronously, i.e. there will be so parallel processing of segments 
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that update the same tables. 
Extract outbound transactions 

Outbound extracts will be controlled by die SCHEDULE_CONTROL uble. 
This table will control the frequency, destination and size of all outbound 
5 files. When a specific extract process is started, the system will: 

1. Creates the file. 

2. Extract all the un-flagged transaction records ftom a 
selected table 

3. Create the required header record 
10 4. Format the detail records 

5. Create the requited trailer record 

6. Closes the file 

7. Mark as "flagged" the un-flagged transaction records 
from step 2 

15 8. Each extract file is assigned a unique name and an 

entry is added to die OUT FILE CONTROL table 
widi die stanis set to "EXTRACTED". 

Transmitting File 

This process will scan die OUT_FILE_CONTROL table for all entries with a 
20 status of "EXTRACTED". For each entry found, a telecommunication 

connection is initiated to the designated party and the file is transmitted. 
Disaster Recovery Copy of output files 

A copy of the output file is also transmitted to the off-site backup server. 
Upon successful transmission, the OUT FILE CONTROL disaster recovery 
25 entry is updated to "SENT". 

Transaction Acknowledgment 
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AH transactions sent to a remote data centre for processing wUl require an 
acknowledgment that the transactions were successftiUy processed or failed. 
These acknowledgments will be remmed in a standard format that conforms to 
the same header, trailer standards as other file formats. By using this format 
the acknowledgment files can be processed using the same standard dataflow 
as mentioned above. 

Puipose of off-site Disaster Recovery Server (DRS) 
Copy of aU files received by IW/TP and Copy of all files transmitted by 
IW/TP. System back-ups will be performed weekly (ftequency may chai>ge) 
and stored off-site. If a disaster occure prior to the next scheduled IW/TP 
system back-up. the previous system back-up is retrieved ftom off-site 
storage. In addition, all the required input and output files are retrieved from 
the off-site Disaster Recovery Server. These input files will be re-processed 
using the last system backup. However, it is possible that the new rewarxls 
generated may not match the ones originally sent to HCC. These output files 
should not be transmitted to HCC untU the new output files are validated. This 
requires a comparison of the new output files with the DRS copies of the 
originally transmitted output files. For each transaction that docs not match, 
an error message and possibly an adjustment transaction should be generated. 



20 Member Module 

This is the main module of the system and it contains pertinent information 
about the Member, i.e. Member Number, name, address, language 
preference, etc. TTus module supplies information to many other supporting 



modules. 
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Member Enrollment Management 

A Partner's customer can become a reward system Member and added to the 
IW Transaction Processing database as follows: 



1. Auto-Prospects - A Partner can supply a "target group" of 
5 valued customers which can be iqiloaded to the database as 

leads( prospects) via tape or electronic transfer. 

Note : They are not automatically enrolled. 

2. Odier methods: 

• Enrollment fonns sent by fax, e-mail, take-ones, or 
10 mail. 

• Enrollment data collected via a telephone call to 
Customer Service Centre 

• Enrolhnent data collected via the IVR system Validation 
of Member data 



1 5 Data for potential new Members can enter the system 

from a variety of sources, but in each case, HCC is 
responsible for validating all new Member data. 

If IW/TP receives information firom Data Eotiy or from 
Partners, IW/TP simply passes on this raw Member 
20 Lead transaction to HCC for validation. 

Referring to Figure 9 there is illustrated, in a flow chart, member lead 

processing data flow for the reward method of Fig. 3. 
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Referring to Figure 10 there is illustrated, in a flow chart, member enrolhnent 
processing data flow for the reward method of Fig. 3. 

Rewards Module 

Partners Rewards- Partners are re^nsible for capturing the reward ^stem 
data and sending it to FTC. Members (using the reward system card) will 
earn points for each dollar spent at a Partner's location. Members will have 
options on "what" currency types tlwy wish to use when redeeming their 
points, i.e. Long Distance minutes. Cellular minutes, etc. 

Data Capture 

There are several methods in which a reward system transaction can be 
captured and sent to the Partner Host. The methods are as follows: 

* POS Direct - data is o^tured via card swipe at the Partner POS. 

* F.I Terminal - data is c^tured on a Financial Institution Terminal 
(Credit/Debit). 

* reward system Terminal - data is o^tured on a standalone reward system 
terminal. 

* Record of Char^ge - data is caittured on chits/paper. 

* PC Direct - data is entered and captured on a PC. 

Reward Credit Transaction Process 

Once die transaction is received at die Partner Host, the foUowmg process is 
executed: 

The Partner then generates a Member Purdiase (MP) transaction and sends it 
to die IW/TP. Procedures and Standards for Data Capture will be provided 
by FTC to die Partner. 

IW/TP receives and validates the MP transaction by Member Number, Partner 
ID, Partner's store location ID, offer codes. Any errors are flagged and 
reported to the Partner. 
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Reward points are likely to be pre-calculated by the Paitner. However, 
IW/TP must verify the points in any case. Using the Offer rate table, the 
reward points are calculated. 

The reward points are analyzed for fraud by comparing the points to pre- 
5 defined Partner thresholds. Any suspected transactions are flagged as 

"suspense" and FTC is notified for manual verification. 
IW/TP generates a Monber Reward Credit (RC) transactions. IW/TP will 
also manage Member and Partner point accumulator buckets. 
The RC transactions are transmitted to HCC. The RC transactions are stored 
1 0 HCC receives the RC transactions and updates the available points for the 

Member on the Debit Platfonn 

The CSC will receive the Reward Credit Transactions via HCC from IW. 
Reward Transaction Triggers 

All of these triggers represent a Reward Credit transaction type. Each has its 
1 5 own set of iHisiness lules: 

Members purchase at a Partner's store 

Purchase of a specific item (bonus offer)Purchase of a ^)eciflc offer of double 
or diple the BASE 

Accumulation of points over a pre-defined time period 
20 Transfer from one Member Number to another Member Number (accoimt) 

Discretionary award frxnn Customer Service Representative 
IVR rewards for completing surveys 
Promotional reward of units 

Reward Redemption 

25 HCC is responsible for managing the Debit I^ocess. This debit process, 

commonly known as redemption is initiated when a Member consumes or uses 
a part of their reward points. TW manages the Member purchases to reward 
"points" conversion process. HCC manages the reward point to "currency" 
conversion process based on the method of redemption, i.e. Long distance. 

30 cellular, video, Internet. 
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Reward Debit Transaction Process 

When the Member redeems his/her points, HCC debits their point balaiK:e 
based on the type of currency used to redeem the points, i.e. 1 celhilar minute 
= 2000 points. A Reward Debit transaction is generated and transmitted to 
IW/TP to keep the systems synchronized. 

Reward Credit Processing 

Rules and standards apply for Credit processing. The rules and standards 
must be authorized by reward system and will vary depending upon the 
Partner. IW and the CSC can generate credits for a Member (upon 
investigation). If IW initiates the credit, a Member Rewaixl Ciedit 
transaction is created and o-ansmitted to HCC. If die CSC initiates the credit, 
a Member Reward Credit transaction is created and transmitted to IW. The 
Member's account will be credited instantly, allowing immediate redemption. 
Referring to Figure 1 1 there is illustrated, in a flow chart, the reward 
transaction process for the reward method of Fig. 3. Referring to Figure 12 
illustrates, in a flow chart, transaction processing data flow for die reward 
method of Fig. 3. 

DATA WAREHOUSE 

Analytical Processing will render the mass of Transaction, IVR and Customer 
Service data intelligible and actionable to these reward system stakeholders: 

• Partner Marketing Team 

• reward syston Account Managers 

• reward system Program Managemem 

• InfoWorks System Administrator 

On-Line Analytical Processing (OLAP) is a system for storing, analyzing, 
reporting and viewing inforaiation about the activity of rewanl system 
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Members. OLAP is distinguished from the TP (Transaction Processor) in 
these ways: 

Storage- Transactions are stored for years, not for only 3 months; 
Database- Tables are optimized for fast, jflexible data access; 
5 Processing- Specialized functions for marketing analytics 

The OLAP System has these major conq)onents: IW Data Warehouse (DW) 
for storage and de-normalized tables for accumulating Member transaction 
data (detail level data), archiving system for low-cost storage and rapid 
retrieval of old detail data. 

10 IW Analytical Processing (AP) for marketing-statistical software procedures 

for reporting and segmenting. 

Partoer Report Repositoiy for file storage and access method for historical 
reports. 

Partner Mariceting Databases (MDB) subsets of data warehouse designed for 
1 5 nuu-keter access at Partner level. 



Graphical User Interface (GUI) to provide 'slice & dice' views of the MDB 
for the FT Account Manager and to provide OLAP system control for the 
InfoWorks System Administrator. 
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Processing Flow includes the sXeps of: 

Validate Input. Running Totals, Upload Format, TP Unit, Procedures. 

Data Warehouse 

Data Collection from IW/TP 

Hie TP will act as a central point of data collection for these reward system 
data sources: 

Member transactions from the Partners : Partner transmissions 
Reward accounting by the TP : IW TP Center 

Debit Platform and IVR activity : HCSC activity 

High-level Control Center 
Data Entry 

Transferring Data from Data Warehouse to IW/TP 

After download to the Data Warehouse, some analytical ptx)ceduics will 

generate Member data values whidi may be of use in these TP functional 

areas: 

Member Reward Status wpat variable in logic for bonus rate 

calculation based on Member segment status i.e. Gold. Silver, Bronze 

Members IVR custom messaging flow through to IVR 

Mail-out messaging flow thru to statement fiilfiUment house 

The Analytical Member data will be processed as a special transaction sent to 

the TP on a WEEKLY basis, taking place after that week's download has 

been analyzed. 

The InfoWorics' Data Warehouse (IW/DW) stores reward system data to 
support the reporting, viewing and analytics fiinctions. The DW has three sub- 
components: 

• Physical Storage Units (ex: DASD drives) 

• Database System (cx: Sybase) 
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• Database Server (ex: Sun 1000)* 

• Archive System (ta^ or optical jukebox) 

Referring to Figure 13 there is illustrated in a block diagram outbound 
activities for apparatus used by the method of Figure 3 

Referring to Figure 14 there is illustrated, in a flow chart, statement 
processing data flow for the reward method of Fig. 3. 



Debit Card Platform 

The reward system PCS system comprises a front end voice application 
that has its own unique call flow as well as a back end database component 
1 0 that will suit the data requirements of the reward system. 

The Control Centre 102 is the interface to die debit platform 112. It 
has access to tables in the reward system PCS database and is able to perform 
reward system and batch updates. The reward system PCS system requires 
access to the HCC 102 tables in order to provide some of the features 
1 5 required by the reward system. 

The main functions and features required for the reward system PCS 
debit platform 112 are described in the following pages. 

The reward system PCS has its own separate master database. 

The tables tfiat are die main concern are the CARD_NUMBER, 
20 CONSUMER_CALL_LOG, and CONS_OUTB0UND_L0G tables. 

It is also more efficient to keep the reward system call detail records 
separate because large call volumes are expected and reward system will be 
using the call detail records for queries by the Customer Service Centre and 
for its own analytics. Call detail records are currently stored in the PCS node 
25 databases but will need to be written to die central master database so that 
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they are accessible to the reward system from one centralized location. 

The reward system member will choose their preferred IVR language 
during enrolhnent. This choice will be validated against the choices available 
on the IVR and will be stored in a language field on the reward system PCS 
CARD_NUMBER table and in an IVR language field on their member 
profile. A member's household language is also recorded on their member 
profile so that analytics can be perfonned to determine the best options for 
future languages in the IVR. 

At launch, English and French arc die two languages Hat need to be 
available on the debit platform. More language options will be required as the 
campaign progresses and will be incorporated by simply recording all voice 
prompts in the new language and making a minor system change to the reward 
system front end voice application to recognize and act on the new language 
code. 

When a member calls imo the PCS system, tfiey will be played a 
"welcome" message and a "request for member number" message in all IVR 
languages. Experienced members will know to immediately key in their 
member number rather than listen to the entire voice prompts. Once the 
member has entered their member number die call will proceed in their 
chosen IVR language. AU voice within the call flow wUl be played in flie 
member's ianguage including branded messages and surveys. 

In an alternative of tbs reward system PCS, a function will be avaUable 
witfiin the IVR to aUow the caller to change tfieir language choice (this will be 
particularly useful as new languages arc added to the IVR). This "change 
language" function wUl be a sub-option under die admmistrative options on 
the main menu. If a member chooses to diange their language in the IVR their 
current call must continue in the new language and die diange must be 
immediately reflected on the reward system PCS CARD NUMBER table. 
Also, a member transaction to die CC must be created to update ttieir member 
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profile. Until this function is implemented, the member can change their IVR 
language through tbt Customer Service Centre. 

Each reward system m«nber immber (card number in PCS) will have a 
password associated with it. This password will be chosen by the member 
5 when they first use the debit platform. It is personal to the member and will 

not be visible to anyone. 

A flag may be added to the CAMPAIGN table to indicate whether a 
campaign uses passwords. As well, a field has been added to the 
CARD_NUMBER table to store the password for the card. The password 
1 0 length is currently set at 4 characters. A change will be made to increase the 

length of the password field to 10 characters and allow the IVR to accept a 
variable length password (minimum 4 to maximum 10 characters). A 
password reset flag will also be added to the CARD NUMBER table so that 
the member can be prompted to choose a new password on their next call. 

1 5 When the member is initially setup in the PCS system their password 

will be blank and the password reset flag will be set to Y to indicate that a 
password needs to be chosen. When the member first calls into the IVR they 
will be prompted to initialize their password. The member must enter a 
password which is then validated (4 to 10 characters). The member is then 

20 asked to re-enter their password for verification. If the two passwords are 

identical, the member's password is set otherwise they must begin the entire 
routine again. On subsequent calls, ttie member will be asked to enter their 
password immediately after entering their member number (the member 
number is validated first). 

25 A function will be available within the IVR system to allow the caller 

to change their password. This will be a sub-option lUKler the administrative 
options on the main menu. If a member forgets then* password, a procedure 
will be in place that will allow a Customer Service Centre agent to reset it 
(this will be an audited process). 
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During the call flow, the membo- will be pieseoted with a main menu 
of rVR options. The entire menu will be soft prompted such that the caller can 
make their selection at anytime while the menu is played. 

The primaiy categories on this main menu will be: 

=» To listen to messages, participate in surveys, and earn reward 
system units, press 1 

=> To place a call, prKS 2 

■=> For administrative options, press 3 

=» For program and/or partner information, press 4 

=» To speak with a reward system customer service centre agent, press 

0 

Additional menu options can be added as required with the 
recommendation that the zero out to the CSC option always be played last. 

A sub-menu will exist under the messages/airveys option and will be 
presented to the caller when they press 1. The primary categories on this 
meini will be: 

«=» To listen to messages from reward system Partners, press 1 
■» To participate in surveys or games, press 2 
■* To roum to tfie main menu, press * 

To speak with a reward system customer service centre agent, press 

0 



The place a call option will lead the caller through entering the 
telephone munber for their outbound call. 
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A sub-menu will exist under the administrative option and will be 
presented to the caller when they press 3. The primary categories on this 
menu will be: 

=» To change your password, press 1 

=> To query yow account balance, press 2 

=> To transfer units to anodier member, press 3 

^ To change your language choice, presis 4 

=» To return to the main menu, press * 

=> To speak with a reward system customer service centre agent, press 

0 

A sub-menu may also exist for the program and/or partner information 
option but will be designed as needed. This may include topics such as "to 
hear a list of reward system Partners", "to learn more about the reward 
system program", etc. 

1 5 The caller will be guided within the call flow to enter the digits for 

their outbound call if they have enough units in their account for a one minute 
call at the lowest rating level (eg. local call). The caller will be able to place a 
national or international call provided that they have at least enough imits 
remaining in tiieir account (after rating) for a one minute call. 

20 Outbound calls to regions within the North American Dialing Plan will 

be rated based on their tspn and nxx in conjunction with the xtpi and nxx of 
the caller. International calls will be rated on the country code that was 
entered. 



5 



10 



25 



With only 1 minute remaining in the call, the caller will be prompted 
with a warning message which states that dieie is only 1 minute remaining for 
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the call. A second warning, with only 10 seconds left, wUl also play. After 
tbeir time has been used, the caller wUl hear a "Your time is up" message and 
wiU be disconnected from their outbound call. The caller may also disconnect 
from their outbound caU by pressing the # key. The caller's account will be 
5 immediately updated to reflect the time used. The duration of the call will be 

rounded up to the next minute and this time amount wUl be translated to units 
based on the rating scheme for the call. After placing a call (either 
successftiUy or unsuccessfiiUy). the caller wUI hear theu" new balance and wUI 
be presented with the main menu. 

^ ° An outbound call that consumes a member's units will also create a 

consumption transaction to the CX: platform for audit purposes and to update 
the member's balance on then- member profile. 

The member will be able to obtain their current account bahmce witiiin 
the rVR. A member's account balance is played to them before the main menu 
15 is presented. 

If a member earns additional reward system units by participating in a 
survey, listening to a special branded message, or playing an interactive game 
then their updated balance may be spoken to them to assure them tiiat they 
have received their reward. 



20 



25 



After a member has cnicred the digits for their outbound call, the WR 
will speak their account balance in tenns of how many minutes they have 
avaUable for fl»e call they have just placed. This balance of time will be 
calculated based on the rate of unit consumption for that call and wUI be 
rounded down to tiic nearest minute. For example, if they have 6 units 
remainiAg in their account but are placing a call that has a 3 units : 1 minute 
rating ratio, then tiiis rated balance wiU read "You have up to 2 minutes for 
tiiis call". If a member's rated balance does not allow for at least a one 
minute call, they wiU not be played their balance but wUl instead be told that 
they do not have sufficient units to place die call. 
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After a member has ended an cnitbound call, they will be played their 
new account balaiK^e and returned to the main menu. 

Branded messages will be offered at two points within die IVR call 
flow. Type A messages are typically short messages (5 - 10s) and are slotted 
5 to play after the member has entered their member number and password. 

Type B messages are typically longer messages (S - 30s) and will be available 
tmder option 1 on the main menu ("To listen to messages, participate in 
surveys, and earn reward system units, press 1"). Type A messages can be 
recycled and played with Type B messages so that a member has the 

1 0 oppoitunity to listen to them again. After the member has entered their 

member number and password, the IVR system will check the CC 
MEMBER_MESSAGE table to determioe whether the member has any Type 
A branded messages that should be played at this time (complete or expired 
messages are not considered). The next message to be played for a member is 

1 5 based on which one has the highest priority and is the oldest within that 

priority level. A message code is returned from the MEMBER_MESSAGE 
table which must then be translated to a voice segment. The message code is 
looked up in the CC BRANDED_MESSAGE table to determine which voice 
segment to play, the type of play (hard or soft), and whether there is a reward 

20 for fully listening to the message. The message is then played to the caller. 

If the caller presses a DTMF key before the end of a soft play message 
(but after 2s of play) then a message transaction record is created with the 
message code, the member number, the length of time the monber listened to 
the message, and a "partially listoied" oaois. If tfte caller fully listens to the 

25 message then a message transaction record is created with a "fully listened" 

stams. If the message was fully listened to and a reward is offered, the 
member's account must be inmiediately updated to reflect the reward and a 
reward transaction must be created and sent to the CC for audit purposes. If 
the caller pressed zero before the branded message finished playing they will 

30 be transferred to the CSC (any other key will not have an aaion associated 
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with it). The member's account balance is played after the branded message. 
It must reflect any additional reward diat was given for listening to the 
branded message. The member will hear a maximum of 1 branded message 
per call. If the branded message is flagged as recyclable, then the message's 
priority for diat monber is lowered so that it will be considered again but only 
after other messages have been considered. If it not recyclable, then the 
message for that member will be flagged as complete. 

If the caller chooses option 1 on the main menu and then selects to 
listen to branded messages, they will be presented with all Type A and Type 
B branded messages. The branded messages will be ordered based on priority 
and age. If the message is soft play, the member will have the (^tion to 
interrupt by pressing a DTMF key which will stop the message from playuig. 
The caller will be instrua that the key is to be used to interrupt/skip a 
message. With this intenupt, or wban the message had finished playing, die > 
caller will be presented with three options. They can listen to the message 
agam. move on to the next message, or return to the memi. After a message 
has been listened to (either fully or partially) a message transaction record will 
be created. If there is a reward for "fiilly listened to" messages, then the 
member's account is iq>dated with the reward and a reward transaction is 
initiated. If the message is flagged as recyclable then the priority of the 
message is lowered so that it moves further down in the queue otherwise, the 
message b flagged as complete and will not be offered to the member again. 

Surveys and interactive games will be offered through option 
1 on the main menu ("To listen to messages, participate in 
surveys, and earn extra reward system units, press 1"). 

If the caller selects option 1 from the main menu and then 
selects to participate in surveys and games, the IVR system will 
check the CC MEMBER_SURVEY table to determine whether the 
member has any surveys or interactive games to present at this 
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time. The member will be able to participate in all surveys or 
games that have been assigned to their member number. The order 
in which these surveys are to be presented for a member is based 
on which survey has the highest priority and is the oldest within 
5 that priority level. The survey codes are returned from the 

MEMBER_SURVEY table and must then be translated to a state 
table name for each survey. The survey code is looked up in the 
CC SURVEY table to determine which state table to invoke and 
whether there is a reward for completing the survey. By branching 
10 to a state table, this survey and game feamre is very flexible and 
can involve anything that is possible within the IVR world. 

The beginning steps of a survey or game will include a brief 
explanation of what it is about. For example, "Partner X will 
reward you with 5 reward system units to answer the following 

15 survey". The introduction will also give the caller an option to 
continue or skip. If the caller chooses to skip the survey or game 
they simply move on to the next survey that was assigned to them. 
If the caller continues and partially completes the survey or game 
then a decision is made within the survey or game whether it 

20 should be made available to the caller again (either to complete or 
to redo). A decision will also be made within the survey about 
creating a survey transaction record for partially completed 
surveys. If the caller fully completes the survey then a survey 
transaction record is created and the survey for that member is 

25 either marked as completed or it is recycled by lowering the 

priority. If the survey was fully completed and a reward is offered, 
the member's account must be immediately updated to reflect the 
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reward and a reward transaction must be created and sent to CC 
for audit purposes. The actual results of a survey or game will be 
transmitted (if necessary) via the CC to the transaction processing 
kernel for analytics. This transmission of results will not be a 
standard transaction as the data produced by a survey or game will 
vary dqiending on the survey or game. 

Wherever a menu selection is offered in the IVR system, an 
option on this menu will be to zero out to the customer service 
centre ("To speak with a reward system customer service centre 
agent, press 0"). Most of the voice prompts that are played to the 
caller are soft play and can therefore be interrupted at any time by 
a DTMF key. If a menu follows one of these prompts then a caller 
pressmg zero during tiie prompt will transfer their call to the CSC. 
For example, the member is listening to their account balance and 
presses zero. This zero interrupts the playing of the account 
balance and is interpreted the same as the caller waitmg for the 
main menu to play and then pressing zero. The member can also 
zero out to the CSC while listening to a soft play branded message. 

There will also be a tunable option (turn it on or oflO that 
will automatically zero out a caller to the customer service centre 
when they appear to be having diflRculty using the IVR system. 
For example, the caller was given two tries to enter their member 
number but die IVR did not detect a response. The caller will be 
told they are being transferred a CSC agent and can choose to 
either stay on the line or hang up. The CSC agent can then assist 
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the caller in determining tiieir difficulty (rotary phone, insufficient 
time, etc). The caller could also be transferred to the CSC if they 
appeared to be deliberately trying to defraud the system (eg. 
member number hunting or guessing passwords). 

5 Alternatively, a transfer to the customer service centre could 

be accompanied by a screen pop based on member number 
information and perhaps based on where the caller was in the IVR 
when they pressed zero. The CSC agent will then be able to better 
assist the caller as they would already have an idea why the caller 
10 was transferred to die CSC. 

Once in the IVR system (member number and password have 
been entered), the caller should be able to transfer units from their 
account to any other valid member's account in the reward system 
PCS. This option will be available on the administrative options 
1 5 sub-menu. 

When the caller chooses the member to member transfer 
option, they will be asked to enter the number of units diey wish to 
transfer. Once the system has validated that the caller did not enter 
an amount greater than their account balance, the caller will be 

20 asked to enter the member number to which they wish to transfer 
the units. The system will then verify that the "transfer to" 
member number is valid. The caller will not be asked for the other 
member's password. The "transfer to" member number and the 
number of units to transfer will be repeated to the caller. The 

25 caller will be given the option to continue (if die information is 

correct) or restart (if the information is not correct). A member to 
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member transfer will immediately update the two members account 
balances. A consumption transaction will be created for the 
"transfer from" member and sent to the CC for audit purposes and 
to decrement the member's balance in their member profile. A 
reward transaction will be created for the "transfer to" member 
and sent to the CC for audit purposes and to increment the 
member's balance in their member profile. Note: the alternative 
option being considered is to send a special member to member 
transfer transaction to the CC for audit purposes. 

Another alternative is to support cellular debit calling. As a 
result of the mobile nature of the caller, issues such as location of 
the caller (roaming or out of home area) must be considered. The 
caller dials something like *99 to connect them to the reward 
system debit application through which they will enter their 
member number and password and place their call. The rating (unit 
consumption) for a cellular call may be different than for a land 
based call and may also involve a long distance debit. The member 
will only have one account of units from which either land based 
or cellular calls are debited. 

The IVR system may be able to expand to include other 
options without significanUy changing the current options - so as to 
avoid confusion for the caller that has become experienced at using 
the system. Other functions may include: faxing of account 
information (may consume units); mformation services (eg. sports, 
horoscq>es) that may consume units per use; etc. 
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2.0 Customer Service Centre 

The Control Centre will be the interface to the reward system 
Customer Service Centre. All mformation that is required for the CSC screens 
will be derived from die CC databases and the debit platform databases. 



5 The Customer Service Centre will have a screen based application to gather 

and access reward system data. The CSC agent's screen is popiilated with 
member profile data as the call is being transferred (provided that the caller 
zeroed out from the application after entering their monber number). 

The following pages contain details on the main areas of functionality 
10 for the CSC application. 

Program Information 



• Explain the loyalty program 

Explain to members and iK>n-members the reward system concq)t, who 
the partners are, how to enroll, how to gather and use units, the rating 
1 5 schemes of the different partners, etc. This information may either be stored 

oidine or in a manual at each agent's workstation. 

• Create fiUfUlmem requests for members 

Generate a fulfillment request in the reward system to initiate a mailout 
of information. 
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• Explain branded messages and surveys 

Give assistance about listening to brairfed messages, answering 
surveys, or playing inteiaaive games that are currently setup in the system. 

Member Profile 

• &iroU new members into the program 

Agents wm be able to collect all pertinent enrollment infoiination from 
the caller into their reward system CSC application. The application wUl guide 
them as to the required information and wiU allow a completed application to 
be submitted to the CC for processing. The enrollee wUl receive their reward 
system card in the mail once the system has processed their application (they 
will not know their member number until they receive their card). 

• Correct em-ollments 

A feature on the CSC application will be to bring forward any 
enroUments that did not pass tfje validation process (eg. incomplete data that 
would prevent tiie enrollee from being properly serviced by reward system). 
The CSC agent wiU place outbound caUs, fill in the missing details, and 
submit the enrolhnent for processing (the enrollment must contain a valid 
phone number). 

• Query member profile 

Query witii member number to retrieve member profde information 
(eg. name, address). (Jueries using other fields will also be required (eg. by 
name). This function wiU be used to personalize Uie conversation between the 
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CSC agent and the member as well as to infoim the agent of special 
considerations (eg. hearing impaired, gold rated reward system member). 

• Update member profile 

A query will be initiated to retrieve the member profile information so 
the CSC agent can verify that tte caller is the member. The CSC agent can 
then change any of the displayed information (eg. name, address, language). 
Note that a change to a member's spoken language will be reflected on the 
debit platform. 

• Retire or reactivate members 

Based on a request to do so by a member, the agent will be able to 
initiate a transaction to the CC to retire or reactivate a member. 

• Maintain a contact log 

All calls between CSC agents and members will generate a contact log 
record so that member's commoits/complaints/suggestions can be collected 
and recorded as part of their profile information. 

• Gather member details/statistics 

The CSC agents may be able to gather remarks about a member that 
would be useful in future dealings with that member (eg. hearing impaired, 
preferred calling time frame for accepting calls, etc.). Also, the CSC agent 
may ask the member to answer survey questions either on die inbound call or 
by making outbound calls. 
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Member Card 

* Initiate a password reset 

Once the CSC agent has verified that the caller is the member, the 
agent can initiate a password reset transaction to the CC. This transaction sets 
the member's password reset flag on the dd)it platfonn which will then force 
than to enter and verify a new password tibe next time they call into die IVR. 
The ability to do diis may be restricted to CSC supervisors as the member will 
be required to give their personal validation number (eg. mother's maiden 
name). 

* Handle a lost card problem 

A procedure needs to be developed to handle this - the details of the 
procedure will drive the system requirements. 

The options are a) to try to determine the member's number so that a 
replacemem card can be mailed to them or b) to re-enroll the member as if 
they had just joined. With option A, a fiilfiUment request will be initiated to 
the CC to send tfie replacement card. With option B, a new emolhnent 
transaction will be sent to the CC, the member will lose their units and reward 
system wai lose any previous data that had been collected on the member. 

• Create a fulfilhnent request for additional cards with the same 
member number. 

• Unlock a member's card 

A member's card is locked by the PCS system while it is in use. It 
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may remain locked if there was a significant system problem while the 
member was using their card. This unlock process will first verify that the 
card is not locked because it is currently in use, then it wijl send a request to 
the CC to unlock the card. The imlock will be immediately effective. 

• Add units to a member's card 

At the CSC agent's discretion, units may be added to a member's card 
to compensate for a problem. These units can be charged to different sources 
(such as a specific partner). This function will initiate a transaction to the CC 
to immediately update the member's balance and create a 
MEMBER REWARD TXN as an audit. 

Member Account Information 

• Query account information 

Query with member munber to retrieve the member's caixl balance and 
a history of debits and credits to their accoimt. 

A member's unit accumulation history consists of reward transactions 
that show how the member acquired their imits and from which source 
(purchases at partners, CSC agents, branded messages, surveys, other 
members). If the reward is a summary reward (eg. it is composed of several 
purchase transactions firom a partner) then it will be highlighted and the CSC 
agent may perform a drill down operation to further define how that sunm»ary 
reward was calculated. 

A member's unit consumption history consists of consumption 
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transactions that show how Ute monber used their units (outbound calls, 
transfers to another member). Outbound calls will show die number that was 
called, the duration of the call, and the number of units that was consumed by 
the call. Transfers will show the member number of the person that the units 
were transfetTed to. 



Note: This information should be at the same level of detail as the information 
displayed on member statements (3 months). 



CC Transaction Processing 

The CC Transaction Processing centre interfaces to the reward qrstera PCS 
system (debit platform), the reward system Customer Service Centra, the 
Transaction Processing centre, and the IVR Enrolhnent process. Transactions 
are received from and sem to these interfaces either in a batch or reward 
system mode. The CC TP centre houses transaction databases that are used for 
audit purposes and weU as for queries from the CSC and the reward system 
PCS. 

There will be a suite of {plications that will handle member 
enrolhnent. The system design to handle these wUl depend on the method of 
enrolhnent. For example, an electronic kiosk may require a direct link to the 
member profile database and may simulate real-time emolhnent. An IVR 
appUcation can capnire DTMF and voice ii^t to create an enrollmera record. 
If enrolhncnts are collected from die customer service centre then screens will 
need to be designed so that the customer service centre agents may enter the 
member information direcUy imo die system. If enrollments arc gained 
through amalgamating with ahcady existmg loyalty programs then a download 
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file from the new partner's loyalty program may be the best solution 
(however, file format and data transfer issues will need to be resolved). 

Member transactions with a type "enrollment" will be sent from various 
sources in either batdi or reward system to the High-level Control Centre for 
5 validation and processing. 



• Collect enrollment data 

Regardless of the method used to collect the enrolhnent data from the 
prospective members, the result will be a transaaion to the CC (either batch 
or reward system). The format of this transaction (MEMBER_TXN) is 
1 0 outlined in the reward system Database Design document. 



* Validate enrollment records 

As enrollment transactions are received, they are validated and 
recorded in the MEMBER TXN table as either new (passed validation) or 
correaions pending (did not pass validation). CSC agents will be able to 
1 5 modify transactions that are flagged as corrections pending and resubmit them 

for processing. Any enrollments that originate from the CSC, new or 
corrected, will have been validated online so that they do not recycle 
continuously through the system causing frustration to both the CSC agent and 
the enrollee. 



20 • Assign member numbers 

A process wiU periodically search the MEMBER_TXN table for 
validated etuollments. A member number will be chosen from the pool of 
unique member numbers and will be assigned to the enrollment to complete a 
new member profile. The member number will be flagged as in use in the 
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MEMBER_^aJMBERS table and tbe new membo- profile record will be 
added to the MEMBER PROFILE table. 



• Activate the new member 

After the MEMBER_PROFILE record has been created for the new 
member, the member will be activated on the debit platform by adding their 
member number to the reward system PCS CARD NUMBER table. 



• Forward member profile to the online analytical processing system 

A batch process will be mn at least daily to send the new member 
profUes, with member number, to the transaction processing kernel. The 
transaction processing kernel wiU add them to their member profde table and 
issue a welcome kit to the new member. The welcome kit will contain die 
member's reward system card with their member number printed on the card. 



Member Numh^r Mni ntenamy 

• Generate new monber numbers 

As the pool of available member numbers declines, new member 
numbers wUl be generated and added to the pool (MEMBER NUMBERS 
table). The generation process will take into consideration all currently 
existing member numbers and will not create diqilicates. 



20 



• Manage the member munbm 

When member numbers are assigned to new enroUments they are 



wo 96/31848 PCT/CA96/00198 

- 48 - 

flagged as in use. They remain in this state until the member retires (or is 
suspended). When a member retires, the member number is removed from the 
debit platform (member deactivated) and it is also flagged as retired in the 
MEMBER NUMBERS table. If the member does not reactivate within a 
5 specified period of time then the member number is made available for reuse. 

Reward system will have to determine a policy with regard to whether a 
member loses their accumulated units by retiring. 



• Database synchronization 

A process will be run periodically to verify that the debit platform 
1 0 CARD NUMBER table remains in sync with the CC MEMBER PROFILE 

table. All member numbers on the debit platform must relate to non-retired 
and non-suspended member numbers in the member proflle table and must 
have the same account balance. 



The CC MEMBER_PROFILE table must contain member numbers that 
match member numbers in the MEMBER_NUMBERS table. The stanis of the 
member numbers must also be similar, that is an in use number in one table 
cannot relate to a retired number in the other. Numbers that are not in use or 
retired in the MEMBER_NUMBERS table must not exist in the 
MEMBER PROHLE table. 

The CC monber profUe table must also be verified with the online 
analytical processing system member number table to ensure that these two are 
identical. 



Member Profile Information 
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Note: The full monber profile database to be used for analytics will be 
designed, developed aiKi managed by transaction processing kerael but a 
subset of this database will need to reside in the CC so that member profile 
information is available to the customer service centre agents. The information 
collected in the CC will pertain to information that is required during the 
enrollment process; information that can be changed by the member calling 
the CSC; and information tiiat can be changed via an IVR fiinction (eg. 
language). All data contained in the CC tables of the member profile database 
will be created, updated, and deleted by the CC. That is, die CC has the 
master version of these tables. A copy of new, updated, or deleted records 
will be sent to the transaction processing kernel so that the correspondirig 
tables in their member proHle database can be maintained. 

• Process member profile iqxiates 

Member profile updates will be received in reward system or batch 
from the customer service centre (eg. name, address) or the IVR (eg. 
language) or transaction processing kernel (eg. from white mail processing). 
The CC will record tiiese transactions in the MEMBER TXN table, validate 
die changes and update its member profile table. It will forward ttese changes 
to the transaction processing kerrol to update their member profile table and 
will also update the debit platform if requued. 

• Process member profile retirements or suspensions 

The customer service centre can initiate retirements or suspensions at a 
member's request or the CC can determine that a member should be retired or 
suspended based on account inactivity or fraudulent use of the system. The 
CC wUl record these transactions in the MEMBER TXN toble. It will forward 
these updates to the transaction processmg kernel to update their member 
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profile table. The CC will also apply these changes as deletes to the 
CARD_NUMBER table in tfie debit platform database. 



• Forward miscellaneous fulfillment requests to the transaction 
processing kernel 

5 Fulfillment requests will be created for welcome kits, replacement 

cards, program or partner information, and account statements. These requests 
will come primarily from the CSC. 



• Forward any member number based data collection to the online 
analytical processing system for analysis 

1 0 This type of information will be from survey refuses or member 

comments that were collected in the IVR or by the CSC. A member's 
demographic information (eg. number of cars) may also be collected via the 
IVR or CSC. These two types of information will not be stored in the CC 
member profile table but will be transmitted to the transaaion processing 

1 5 kernel to be stored in their data warehouse. The type of information collected 

may vary so a flexible process needs to be developed to handle this data 
transfer. 



M«nber Reward Transactions 



• Receive member reward transactions from the online analytical 
20 processing system 

Initially there will be a batdi process for transmission of this data. 
These rewards are derived from member inirchases from partner point of sale 
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systems. The reward, with purchase infonnation. is captured in the 
MEMBER_REWARD_TXN table for audit purposes and for die CSC 
interface so diat an agent can explain to a member how they earned Uieir 
units. After the transactions are added to the table, they are summarized by 
5 member number and the member's balance is updated with the reward on the 

debit platform CARD NUMBER table and on the CC member profUe table. 



• Receive member reward transactions from the Customer Service 

Centre 

These rewards are generated when a CSC agent gives a member units 
because of a problem they experienced. They are sometimes associated to a 
particular partner if the member's concern relates specificaUy to a partner. 
The reward is captured in the MEMBER_REWARD_TXN table with the CSC 
agent's id for audit purposes and for queries by die CSC. Immediate reward 
system update to die member's balance on the debit platform 
CARD NUMBER table is required. The member's balance on the CC 
member profile table is also updated. 



• Receive member reward transactions from the dd>it platform 

Reward transactions will be received from the debit platform for 

member to member transfers of units, branded messages, and survey 

completion. These rewards have ah«ady been added to the member's balance 

in the CARD_NUMBER table but need to be added to the member's balance 

on the member profile table. Tbey also need to be captured in the 

MEMBER_REWARD_TXN table for audit purposes and for queries by the 
CSC. 
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• Transaction audit trail 

The CC syston should be able to track all transactions and if necessary 
re-process any transactions that were not processed successfully. The system 
should also be able to reverse any transactions that were seat in error (backing 
out a reward from a member's balance if necessary). 



• Repoit any errors/anomalies 

As reward transactions are processed, they will be validated and 
analyzed for errors such as unknown monber number or "large" reward, etc. 
A facility will be provided to review and correct any errors/anomalies and 
10 resubmit the reward transaction for processing. 



• Send member reward transactions to fte online analytical processing 

system 

Online analytical processing system will need a copy of reward 
transactions for rewards that were not generated by purchases (eg. units 
1 5 awarded by the customer service centre or from a survey) so that the 

information is available for statementing, billing, and analytics. This 
information will be sent in a batch process. 

Member Consumption Transactions 



• Receive member consiunption transactions from the debit platform 

20 Member consunqnion transactions will be generated by the debit 

platform for outbound calls that consume a member's units. The member's 
balance on the debit platform CARD_NIJMBER table has already been 
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updated but the member's balance on the CC monber profile table needs to be 
updated. The consumption information is captured in the 
MEMBER_CONSUMPnON_TXN table for audit purposes and for the CSC 
interface so that an agem can explain to a member how they used their units. 

• Receive member consumption transactions for transfers 

A member to member transfer will generate a reward for one member 
and a consumption for the other. If this transaction originates from the debit 
platform then both members' balances on die debit platform have already been 
updated but the members' balances on the CC member profile table need to be 
updated. If this transaction originates from the CSC then the members' 
balances need to be updated on the debit platform CARD_NUMBER table and 
on the CC member profile table. This transaction will be captured in the 
MEMBER_CONSUMPTI0N_TXN table for audh purposes and for queries by 
the CSC. 

• Send member consumption transactions to the online analytical 
processing system 

A batch process will extract and send die member consumption 
transactions to flie transaction processii^ kernel so that the information is 
available for statementing and analytics. 

• Transaction audit trail 

The CC system should be able to track all transactions and if necessary 
re-process any transactions ttiat were not processed successfully. The system 
should also be able to reverse any transactions that were sent in error (backing 
out a consumption from a member's balance if necessary). 
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• Report any errors/anoimlies 

As consiinq)tion transactions are processed, diey will be validated and 
analyzed for errors such as unknown member number or "large" 
consumption, A facility will be provided to review and correct any 
5 errors/anomalies and resubmit the consunq}tion transaction for processing. 

Branded Messages 



• Forward a list of valid branded message codes to the online 
analytical processing system 

Once a branded message has been recorded and semp on all the IVR 
1 0 nodes and a code has been assigned to uniquely identify the message, it will 

be sent to transaction processing kemal so that members can be assigned to 
listen to the message. The information about a branded message is stored in 
the CC BRANDED MESSAGE table. 



• Accept from online analytical processing system member message 
1 5 assignments 

A batch file containing a list of targeted member numbers with a 
corresponding branded message code and priority will be salt from die 
transaction processing kemal to the CC. As the CC processes this file, it will 
add the member number and branded message code combination to the 
20 MEMBER_MESSAGE table. There is a need to quoie many messages for a 

member but to only play one per call. The member message table is 
essentially the member's queue of messages from which the debit platform 
chooses the next message to be played to the member during their call into the 
rVR. 
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• Funnel member message information back to online analytical 
processing system 

When a branded message has been listened to by a member, either 
partially or fiilly, a record is created in the message transaction table 
5 (MESSAGE_TXN). This table records the date and time that the message was 

listened to and how much of die message was listened to by the member 
(number of seconds). A batch process will extract and send member message 
information to transaction processing kernel for "listened to" messages. 

• Record and apply rewards (if applicable) for fully listened to 
1 0 messages 

• Automatically expire branded messages after a preset date 

• Cancel branded messages at any time 

Member messages can be cancelled either specifically by member 
number or globally like the expuy. 

'5 Surveys for Interactive Qamy !^ ) 

• Forward a list of valid survey codes to online analytical processing 

system 

Once the survey or interactive game has been developed and setup on 
all die rVR nodes and a code has been assigned to uniquely identify it, it will 
!0 be sent to transaction processing kernel so that members can be assigi^ to 
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the survey. The information about a survey is stored in the CC SURVEY 
table. The call flow position field in this table will determine where in the call 
flow the survey can be offered. 

• Accept from online analytical processing system survey assignments 

A batch file containing a list of targeted member numbers with a 
corresponding survey code and priority will be sent from transaction 
processing kernel to the CC. As die CC processes this file, it will add the 
member number and survey code combination to the MEMBER_SURVEY 
table. There is a need to queue many surveys for a member but to only play 
one per call. The member survey table is essentially the member's queue of 
surveys from which the debit platform chooses the next survey to be played to 
the member during their call into the IVR. 

• Funnel member survey information back to online analytical 
processing system 

When a survey has been fiilly completed by a member a record is 
created in the survey transaction table (SURVEY TXN). This table records 
the date and time that the survey was completed. A batch process will extract 
and send member survey transaction data to die transaction processing kernel 
for completed surv^s. The survey responses will be sent to the transaction 
processing kernel through a separate process as tiiis information will vary 
depending on the design of the survey. 

• Record and apply rewards (if applicable) for successfully completed 
surveys 
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• Automatically expire surveys after a preset date 

• Cancel surveys at any time 

Member surveys can be cancelled eittier q)ecifically by member 
number or globally like the expiry. 

5 Fraud Detecfiiyn 

• Provide system alarms and procedures to detect atKl deal with 
fraudulent card use. 

Telecommunications Reporting 

• Manage the reward system call detail records on the debit platform 

^ ° If infonnation is required for analytics, then extract it and send it 

to the transaction processing kernel. A history wUl be maintained for bUling 

purposes as well as for telecommunications analytics. The CC wiU control the 

archiving of the cdr information from flie reward system 

CONSUMER_CALL_LCX} and CONS_OUTBOUND_LOG tables on the debit 
1 5 platform. 

• Provide information and reports that can be used to opaaaze 
telecommunications 

Reports will be available to analyze the system usage and capacity 
requirements with regards to call volumes and peak periods. These reports 



96/31848 PCT/CA96/00198 

- 58 - 

will be used to optimize all aspects of the telecranmunications from 800 
number translations through to the Summa and DirectTalk. 
Telecommunications reporting will also analyze the batch and reward system 
transaction processing of the CC. 

Numerous modifications, variations, and adaptations may be made to 
the particular embodiments of the invention described above without departing 
from the scope of the invention, which is dcHned in the claims. 
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CLAIMS: 



1. A method of providing telecommunications rewanls to a 
member comprising the steps of: 

generating a point-of-sale transaction; 

relating the point-of-sale transaction to a member of 
telecommunications awards; 

determining value of reward in dependence upon the point-of-sale 
transaction; 

updating a member's profile for the member by the value determined. 



2. A method as claimed in claim 1 wherein the step of generating 
a point-of-sale transaction includes the steps of scanning a UPC code card of 
the member, and looking up the UPC code in a UPC database. 



3. A method as claimed in claim 1 wherein the step of determming 
value of the point-of-sale transaction to a member includes die step of 
1 5 referring to the member's profile and a rewards file. 



4. A system for providing telecommunications rewards to a 
member comprising: 

a data collection Systran; 

a customer service centre; 

20 enrollment processes; 
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a transaction processing system for managing data firom the point-of- 
sale collection system and members and for calculation of rewards; 

a control center for processing system transactions for the customer 
service center, system access, debit platform management aiKi enrolling 
processes. 
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